The Java programming language enables a programmer to write an application in a single language, and have that application run on various different sets of hardware. So long as a set of hardware has a compatible Java platform executing thereon, it will be able to execute the application. A Java platform typically includes a Java virtual machine (JVM) and a set of application programming interfaces (API's). The API's may be invoked by the application to implement many low level and perhaps even high level functions.
Currently, there are three major Java platforms, each of which targets a different domain. The Java enterprise edition (EE) platform targets enterprise scale systems having large amounts of resources (e.g. large number of processors, large amount of memory and storage, etc.). The Java standard edition (SE) platform targets standard systems, such as desktops and laptops, having standard amounts of resources. The Java micro edition (ME) platform targets smaller devices, such as cell phones, personal digital assistants (PDA's), set top boxes, etc., which have limited processing capabilities and limited memory and storage. The API's available in a sub platform are largely a subset of the API's available in a higher level platform. For example, the API's available in the SE platform are largely a subset of the API's available in the EE platform, and the API's available in the ME platform are largely a subset of the API's available in the SE platform. Thus, not all API's are available on all Java platforms. In addition to these API differences, the behavior of the API's may also differ from platform to platform. For example, both the SE platform and the ME platform may provide a method X, but the behavior of method X may be different on SE than it is on ME. Because of these differences, it is typically not possible for an application written and intended for one platform to be executed on another platform. If it were executed on the unintended platform, the application would most likely not produce the same intended results.
In some implementations, it would be desirable for an application written for one platform to be executed on another platform. For example, it has been noticed that, in many instances, it would be advantageous to be able to execute an application written for the ME platform (i.e. an ME application) on the SE platform. To accommodate this, the prior art has taken several approaches. A first approach provides both platforms on the same machine. If an ME application is executed, then the ME platform is executed to support the ME application. If an SE application is executed, then the SE platform is executed to support the SE application. This approach is undesirable because it requires the porting of both platforms onto the same machine, and it is inefficient to execute different platforms to support different applications. Another approach changes the underlying platform to support the execution of different applications. For example, the SE platform may be changed to check for the platform for which an application is intended. If the application is intended for the ME platform, then a first set of API's are implemented, and if the application is intended for the SE platform, then a second set of API's are implemented. This approach is undesirable because it is quite intrusive (the platform has to be extensively changed) and because it would add significant overhead.
As the above discussion shows, the current approaches have significant drawbacks. As a result, a need exists for an improved approach for enabling a set of code intended for a first platform to be executed on another platform.